The prepared developer writes better code

There are no secrets to success. It is the result of preparation, hard work, and learning from failure. Colin Powell

Look beyond today and plan tomorrow #HoskWisdom

Many developers believe writing code is the most important part of development but you can’t create good code without being prepared.  Preparation, planning and understanding requirements helps find problems in solution design and before you create code.

Lack of preparation results in stuttering development, slowed by bugs, missing requirements, technical debt and late delivery.

While persuading my son of the benefits of getting to football early (more practice, more play with his friends and more football), I said the early bird catches the worm; he said the early footballer catches the ball, but what does the early developer catch?

The early developer catches the bug

Replace early with prepared and getting clarity before you code.

Doing things last minute.com, winging it and making it up as you go creates half.  You might disagree, thinking about the time you winged it and it worked but what about the times you were unprepared, usually it results in lower quality work which took longer.

The result of a bad decision can work once but constant bad decisions don’t work in the long term.

Quote from Bill Walsh on being prepared.

“Hearing someone described as being able to “Fly by the seat of his pants” always suggests to me a leader who hasn’t prepared properly and whose pants may soon fall down.” Bill Walsh

Being prepared makes the most of a situation and you can prepare for other outcomes.

If you know the goal, you can get there in the most direct way.

Meetings

A bad meeting has no agenda, too many people, not the right people, not the right materials. The result is a boring, frustrating and ineffectual meeting which takes longer.  A common goal of meetings is to decide but you need information, options, evaluate before you can decide.

A good meeting has an agenda, it allows attendees to be prepared and focused on the topic, it has decision makers and only the people needed.  creating an agenda, preparing material and only inviting key people takes preparation, but it maximises the time of the people invited.

The focus is on the goal and the purpose. The meeting runs to a schedule. The meeting is followed up with a summary, actions, owners and deadlines.

Coding

Bad
A Developer gets a user story, hasn’t read it before, doesn’t understand the business needs or the purpose behind the requirement. Skims the story, jumps to the acceptance criteria and codes.

Result
Developer finds the story is in complete, acceptance criteria missing, has to ask questions, who asks the business, developer waits, he can’t start anything new because he is halfway through. Gets more requirements, repeats the cycle as they get into the details. Developer codes the rest of the story.

The code is built on a changing design. No coherent structure. Duplicate code used because developer hasn’t prepared or designed the code.  Creates new code in an inconsistent style and standards, this gets rejected at code review and he has to fix, developer frustrated.  The developer has looked at the code base to see what’s there, hasn’t read the standards document.

Developer told to write unit tests.  Tester finds bugs, goes back to the developer.  Users test and find it doesn’t do everything they need and find bugs. Code squeezed in to fix bugs making it harder to understand, maintain and extend.

Good example
Developer reads documentation and understand what the business is trying to do, the purpose of the business and the functionality. Developer reads requirements, asks the tester to make sure the requirements are testable. Questions get raised with business, fuller requirements.

The requirements are understood and the technical design is created and discussed before development starts.

The Developer understands code base, structure and what is there. Designs solution using existing code to avoid duplication and improve consistency.  The developer writes unit tests agaisn’t requirements.  The developer considers not only the happy path but tests exceptions, errors and other paths through the code.

The earlier you find problems the smaller the feedback loop and the quicker you can fix it.  The path you want to follow is fixing problems as near to the source as possible, the fewer people and environments you find the problem quicker the bugs are found and fixed.

Testers will find bugs, the developer will take these bugs and create unit tests to fix the bug and then code it.

Conclusion

Lack of preparation shows in execution.  Preparation allows you to get the right information, consider other options and think about the situation.  An example is presenting, if you prepare and practice it, you deliver a better performance, you can concentrate on the delivery not just the content and make a bigger impact.

For Developers the writing of code is one part of the solution, being prepared saves times and create a higher quality code base with less technical debt.

If you look ahead for bumps in the road you can avoid them